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ABSTRACT 



This paper proposes an Internet facility that will 
authentically provide laboratory experiments remotely. Such a facility is 
brought to the doors of the distance learner to help provide learning that is 
comparable to that offered for conventional students. The paper describes the 
development of a prototype remote laboratory system, including software, 
hardware, procedures, and instructional systems. This includes surveys of 
existing alternatives (mainly software simulation environments) , a 
description of the prototype remote laboratory environment, and a discussion 
of development issues, such as the reasons behind Java and RMI (Remote Method 
Invocation) as the system's development tools over other popular 
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^ authentically 

^vide laboratc^ expenments remotely. Such a facility is brought to the doors oftte 
^ce l^er to help pro^de learning that is comparable to that offered for conventicil 
studtmts. Dm paper descnbes the development of a prototype remote laboratory system 
mcluding sofWare. hardware, procedures, and instructional systems. Diis includ^stiveys 

TTr simulation environments), a description of the 

^totype remote lab environment developed by the authors, and a discussion of 
development is^es, such as the reasons behind JAVA and RMI as the system’s 
development tools over other popular alternatives ^ 



Introduction 



th t f become a powerful educational tool to reach students at times and nlaces 

SalwT educational institutioa New technology has made it possible to ove^ome 

^de^ o'^s^acles of distance m the educational process. Electronic maU, chat roomTand live interactive 

*»®^P *^8 together the people involved in the educational process. The 

World Wide Web has made available many of the resources that uqed tn Iv* j. • i 

camp^(Alhalabi, Sudeep, 1998; Harasim, Hiltz, Teles, & Turoff, 1995; Turoff i°994) 

fe Recess of DL, Wever, has been problematic for courses that require extensive use of laboratorv 

facihties. In such comses, learnmg processes (i.e., problem solving and exploration) via laboraS 
experiments are indispensable. Thus, the distance learner has experienced a void, as no amount of theoretS 
ex^auon can 1^ a quahty surrogate for real laboratory experimentation. Die challenge is to &d ways to 

ra ^ participate in laboratory experiments. 

& 9 . L <=^ntly available Internet-based educational modSes (^alabi Hamza. 

& Sudeep. 1998). the authors surveyed a large number of online courses, distance education aid 

t?’ ^ universities that are involved and actively taking part in DL programs 

In ^ntrast to the simulated laboratories, this paper provides a conceptual proposal for the 

STt environment where authentic laboratory experiments can takfplace via toe 

Internet through remote access. Students have unrestricted freedom to apply any inputs and acqirire resulting 

^ nietood cL Ubite^tud^ts Srph^S^^ 
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Thus, the authors of this paper, propose an Internet facility that will authentically provide laboratory 
experiments remotely. Such a facility is brought to the doors of the distance learner to help provide learning 
that is comparable to that offered for conventional students. Tins paper describes the development of a 
prototype remote laboratory system including software, hardware, procedures, and instructional systems. This 
includes a description of the prototype remote lab environment developed by the authors and a discussion of 
development issues, such as the reasons behind JAVA and RMI as the system’s development tools over other 
popular alternatives. 



Distributed Interface and Protocols 

Java Language 

Java was chosen for several reasons for the implementation of remote labs. Java allows for programs 
that can be embedded in Internet web pages. Currently many applications, which are written in a wide variety 
of languages, including C++, C, and Pascal, have fairly low level facilities like protocol handlers. As remote 
laboratories rely on the Internet, Java was chosen due to its Internet readiness (Ince & Freeman, 1997). 

Java is a machine-independent language, which creates programs that run on a wide variety of 
computers using a range of operating systems. Since students will log on from a variety of computers to 
attend the labs, it is more efficient to choose Java, which inherently solves the problem of portability 
(Flanagan, 1998). 

Java programs do not execute directly on the computer and hence will not interfere with the operating 
system or user data. Instead, they run on the Java virtual machine, solving the problems of security and 
unauthorized access. 

Java is a language well suited for interactive web applications. Most of the applications which are built 
in other languages, such as CGI and HTML, give the impression of being interactive. But in reality they 
usually move through a series of text and visual images following pointers to other sections of text and visual 
images. 

Java language offers the feature of multithreading. This means that there are multiple concurrent 
executions of code, providing a high-level implementation of concurrent processing. This allows many 
students to woik on the same laboratory setup simultaneously (Geary & McCleallan, 1998). 

Java is an Object Oriented programming language. It offers facilities to define and manipulate objects, 
which are self-contained entities that have states and accept messages. Therefore, Java programs can be easily 
modified, as reusability of code is possible (Cornell & Horstmann, 1997). 



Distributed Interface Protocols 

Since the virtual online laboratory will be a distributed environment, the implementation had to be in 
CGI, JDBC, Sockets, IDL, or RMI methodologies. RMI was chosen to build the distributed computing 
environment, written purely in Java, Other distributed computing environments are compared to RMI below. 

The Common Gateway Interface (CGI) is a standard interface that allows web developer s to ex ecute 
programs on an HTTP server. This is a very crude form of client-server computing whereby an HTTP client 
invokes a program running on the server (usually passing it some data), and the program sends some results 
back to the client for display on a browser. CGI programs operate in a stateless mode, which means that there 
is no persistent connection maintained between the client and the server programs. Bach time the CGI 
program gets invoked its runtime environment (memory and system variables) also gets re-established. The 
program being executed sends the information back to the client and the process shuts down. These recurring 
starts and shutdowns generate an extra oveihead in the server’s load and cause delay in the performance. In 
contrast to CGI, RMI operates in a persistent mode. In other words the network session between the client and 
the remote objects remains active until the client or the server closes the connection. RMI’s garbage 
collection process automatically closes the TCP stream when the remote object is no longer referenced. 
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Because of its pereistence, RMI is far more effective than CGI in cases where the client is r unnin g within the 
Java virtual machine. The extra overhead is eUminated and the performance is improved. 

In soine enviroiments, JDBC calls are managed directly by the clients (Reese, 1997). A few JDBC 
drivers require direct interaction with native database drivers such as the Microsoft ODBC, Oracle SQL Net, 
etc. The security contained within most commercial browsers prohibits the execution of native code by the 
Java applets (Cornell & Horstmaim, 1997). Other JDBC drivers remove the native calls by introducing an 
appUcation server. The appUcation server operates as a form of middleware, performing all database 
mteractions and session management on the server. When JDBC calls are incorporated in large-scale 
applications, such as maintaining student records, it is extremely difficult to maintain the up-to-date database 
drivers on every client. .Mso, if either the database engines or the middleware were replaced by another 
product, every client application that accessed it would require modifications. The JDBC client is responsible 
for managing the database session and processing the Information. This might cause the network to be 
burdened with additional traffic as the client repeatedly communicates with the database. In contrast, RMI 
allows par^tioning of data access and workload from the client by encapsulating the JDBC code within a 
remote object This approach eliminates added maintenance of the client-side drivers. This also reduces the 
network utilization by placing the RMI server physically closer to the Database server on the network. In this 
case a single server was used both as a database and for RMI. 

The actual exchange of information between the client and server is performed through the TCP 
sockets. Architecturally the RMI process operates in a very similar way to those written with Socket objects. 
Both support persistent network coimections between the client and the server (Horton, 1997). In RMI 
information between the cUent and server objects is performed through object serialization. However in 
Sockets one must create the program logic to marshal and unmarshal the objects that are serialized. The RMI 
is a higher level architecture than sockets. Although the two perform similar functions, the RMI allows you to 
concentrate on value-added program logic and not network or object transports. 

The IDL or Interface Definition Language (Baker, 1997) is a standard defined by the Object 
Man^ement Group for defining object interfaces. This is intended to establish the object’s interface 
definition regardless of the programming language and environment within which it is implemented. The IDL 
operates in a model that is sircar to the RMI, making use of stubs and skeletons to marshal parameters 
between objects. RMI is useful in brokering object requests when the objects are written purely in Java. 

Although there are many alternatives for building distributed applications like ours, RMI shows its 
strength in severd areas. Since we will be writing the code in Java it is completely portable. It also facilitates 
application partitioning as the communication takes place across virtual machines. The JDBC package was 
used as an interface for executing SQL statement (Reese, 1997). We implemented it in this way because: it 
helps large-scale applications like ours to be written to the JDBC interface without worrying much about 
which database will be deployed with the application; it keeps the main application insulated from vendor 
specific issues, so Ae application can run equally well on Oracle or Microsoft- Access (see Figure 1); the 
JDBC is built on drivers based on other databases API’s, and they are very closely and deliberately mapped to 
the ODBC counterparts, sharing conceptual components like Driver Manager, Connection, Result Set etc. 




FivnrP 1 ? Wnrlnna Friv^mrirrimit Mrvlftl fnr thft Pi-motft T ali SvcfPim 



System Hardware and Software Model 

Hardware Model 

For a prototype, we have built a remote laboratory for experimentation with electronic circuits. The 6B 
Series product family ftom Analog Devices was used to build the required hardware as it provides a direct 
interface between the host computer and a variety of analog input, analog output and digital I/<^pphcations. 
The hardware consists of analog input and output modules and the 6B50 digital I/O 
input modules were used in the circuit; the 6B12 Module accepts millivolt inputs from 150mV to 50toV, 
voltage inputs from IV to 50V and process current inputs, returning dato in engmeenng umts; the 6B21 
Module is an analog output module that provides digitally controlled, isolated current loop output to a 
resolution of 12 bits vrith an output range from either 0 to 20mA or 4 to 20mA. 



System Software Model 

The JDBC-ODBC bridge is included in the JDK 1.1 which enables Java applications to access ^ta 
through drivers written in the ODBC standard. The driver bridge is very useful for accessing data m (tota 
sources for which no pure JDBC driver exists (see Figure 1). Through RMI a student can access any other 
Java object running on a separate virtual machine where the serial communication and the da^^e accesses 
are performed. The Java applets, on which the students are working, invoke methods contamed m remote 
objects, which issue the calls for serial communication and database access. 

The RMI architecture shows the student (client) process and the remote object (a particular experimrat) 
running on separate virtual machines. These two are logically linked to each other through the registty. ^e 
Java virtual laboratory application executes as a server process on Virtual Machine A. "ntis apphcation (the 
remote object), identifies itself with the RMI registry, which is another Java application whose role is to 
maintain active references to remote objects. A stub is a proxy for the remote object implementing its pubhc 
interface. When a student object references a remote object, it does so by referencing its stub. A skeleton is 
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the stub s counteipart running on the remote server. Similar to the smb, it provides the mechanism for 
^cephng smdents requests, forwartog them to the remote object and sending results back to the smdents. 
^ough the registry the remote objects olfer their services to the smdents. When the smdent working on 
Vum^ Mactoe B wishes to mvoke a method contained within the remote object, he/she first communicates 
with the smb. The smb passes the information to the object reference, which requests the service from the 
registry. Tte registry p^ses the request to the remote object through the skeleton. The smdent talks to the 
remote object by accessmg the RMI registry on the host where it resides, through a TCP socket connection 
(i.e. , the Internet). Once the registry accepts the smdent’ s requests, it delivers a reference in the form of a smb 
back to the client. 

The smdent now invokes a method contained within the remote object’s smb. This invocation may 
involve exchange of additional objects as parameters to and return values from the fimction caU. Making both 
the server and the smdent s applet code serializable makes this communication possible. 

At the server end, the parameters, such as the results of the experiment performed and the grade of the 
smdent m an experiment, are forwarded to the remote object through a skeleton object. The skeleton 
dispatches these parameters to the remote object and invokes the appropriate methods. When this function is 
completed the return value is sent back through the skeleton and the stob objects and is received by the 
smdent as shown in Figure 1. The remote object and the smdent lie at the same level of communication i.e. 
any r^uest by the smdent can be answered only by the remote object and vice versa. The same is true for the 
smb-skeleton and the RMI registry object reference. The Security Manager in RMI (Horton, 1997) also makes 
sure that the appropriate measures are implemented to make sure that the application is weD behaved and 
^es not violate the laboratory rules. With the help of the security manager the smdents will be prevented 
from accessmg restricted information, such as grades, on the server machine. 



Implementation Details 

smdent goes to the URL (http://jupiter.cse.fau.edu/directory.html) the ClientApplet gets 
loaded (Geary & McQeaUan, 1998). The browser now halts and the RMI procedures associated with the 
browser start by establishing a one to one connection with the Virtual Laboratory server 

When die applet runs, it automatically connects to the remote objects because the start method of the 
applet con^s toe remote objects’ IP address and toe remote object registry name. Once toe connection has 
b^n estabhshed, RMI will get toe Remote Object Proxy into toe users’ machine, and this proxy has toe 
reference of toe remote object RMI has server-side skeleton and client-side smb. Once toe smdent invokes 
any methods the smb interacts with the skeleton and retrieves toe required remote object (see Figure 1). 

The smdent can invoke all toe methods of toe server (remote objects) fiom toe client program with toe 
use of the smb. The server contains toe skeleton of the remote objects (smbs and skeletons are generated by 
the RMIC compUer provided in toe JDK kit). The skeleton knows toe location of toe remote objects in toe 
rnemory of toe server. Wheti toe client invokes toe method, toe smb sends toe message to toe skeleton; toe 
skeleton calls the remote object; the remote object does the work requested by the client and replies to the 
server skeleton. The skeleton then replies to toe client smb and toe smb sends the message back to toe client 
Following is an example of smdent registration into toe virtual laboratory. To register, toe smdent types 
m h^er lop name and password and clicks on toe register button, invoking toe RegisterQ function in toe 
applet whrch gaps the login name and password. The OpenDirectoryO function will return the thread number 
for that smdent (Horton, 1997). Usmg this thread number toe remote object’s method is called with toe login 
name and password as parameters. This caUs another method for database connection using toe JDBC 
pdefined conamand for SQL query, which checks if any other login name in toe database matches toe one 
toe user has entered. If it does, a message is sent to toe ClientApplet code which asks toe user to try another 
logm name. If no duplicate login exists the login name and password are inserted into the database and a 
posrtive message will be sent to ClientApplet code which informs toe user that registgration has been 
mccessful. At toe end, PerformLoginO calls toe aoseDirectoryQ function that closes toe connection between 
toe clrent and toe remote object (Horton, 1997; Bishop, 1998). 

The registered smdent enters his login name and password and clicks on toe Login button invoking 
PerfompjgmO m toe applet. The OpenDirectoryO function will return toe thread number for this particular 
chent. Usmg this thread number toe remote object methods are caUed and the login name and password are 
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passed as parameters. This method calls another method for database connection using JDBC predefined 
command for SQL query. This method checks if the smdent’s login is present in the database. After the check 
is made, it asks the student to perform Experiment Number 1, if not already performed, or to click on the Get 
Grade button to see his/her grade in the lab. Finally, PerformLoginO calls the QoseDirectoryO function, 
which closes the connection between the client and the remote object. 

If the student has not performed the experiment the student selects Experiment Number 1 from the 
choice menu and clicks on the Get Experiment button. This will build a new panel, which consists of the new 
experiment. The Get Experiment button wUl be enabled only if the student has not performed the experiment. 
Once the experiment number 1 panel is built the student enters three different values for the current The 
smdent can now click on the Run button, which invokes PerformHardwareO in the client applet This function 
grabs the current values entered by the student in three different strings. OpenDirectoryO will return the 
thread number for that particular client The data, which the student has entered needs to be passed to the 
hardware connected to the serial port of the server. Since the Java Virtual Machine cannot interact with *e 
serial port of the server directly or the operating system, the Win32Port class is developed. The values, which 
the student enters, are passed as parameters in the function calls to the Win32Port class. The output results are 
received by the function provided by the Win32Port class methods and these are then passed on to the 
students as outputs of the experiments. Finally, PerformHardwareO, calls QoseDirectoryO which will close 

the connection between the client and the remote object , 

After the student has submitted the data to the hardware and gets back the results, the Submit For Grade 
button is enabled, which will invoke the performSubmissionO function in the client applet This function 
grabs the values of the currents, entered by the student and the voltage values and calls another method for 
database connection using JDBC predefined command for SQL query. This will insert all the values along 
with the student’s name in the database. A positive message will be sent to ClientApplet code infonning the 
user that the values have been successfully submitted. Finally, performSubmissionO calls QoseDirectoryO, 
which closes the connection between the client and the remote object 



The Hard Part: Java Native Interface (Serial Port Communication) 

The last part of completing the package was to write a native interface in Java that talks to the Serial 
Ports This consists of Java code (a class) that accesses data through native methods, which are typically 
particular to a vendor library. Like the bridge driver this class is convenient when a C data access library 

already exists, but it isn’t always very portable. u u w 

The Win32Port class implements the access to the computer’s commumcation ports through the Wm32 
API. The native methods are contained in the JWINPORT DLL, and the Win32Port class is the Java interface 
to them. The DLL is built using the JNI, which comes with Sun’s JDK 1.1. 

The standard drivers for serial ports in Windows 95/NT are limited to the ports COMl through COM4. 
The compiled DLL adopts this limitation and provides space to handle the four ports. However, the multi-port 
interface card with a Windows driver makes additional ports visible for the operating system like the standard 
ports. In this case the DLL has to be recompiled for the number of ports needed. 

The port number is passed to each of the methods as parameter rather than having it as a field of the 
Win32Port class. This is because to access an object field from the C code, a symbolic look up must be made. 
The port number parameter on the other hand gets passed as a plain integer and works faster. 



Conclusion 

The authors are successfully progressing through the design and the implementation of the Virtual Lab 
process over the Internet Unlike time-shift instruction (experiencing instruction following the live lesson, 
i.e., videotape, or a software simulation), real labs or real-time instraction (experiencing instraction at some 
point during the live lesson or experiment) provides students the ability to receive instructions without the 
teacher’s direct presence. Students in Real Lab environments have the freedom to analyze their experiments 
at a By no means is the student thinking limited but instead his or her complex thinking processes 
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(basic thinking, creative t hinkin g, critical thinking) are stirred at a distance with out any technical limitation 
of any kind. A student is stiU able to conduct an experiment, collect needed information, categorize the 
information, synthesize the information, and create his or her own conclusions based on data collected, from 
input and output, without physically attending a lab. 
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